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Abstract 

From user requirements definition to 
accepted software system, the software 
project management wants to be sure that 
the system will meet the requirements. 

For the development of a telecommunication 
satellites Control Centre, C.N.E.S. has used 
new rules to make the use of tracing matrix 
easier. From Requirements to Acceptance 
Tests, each item of a document must have an 
identifier. A unique matrix traces the 
system and allows the tracking of the 
consequences of a change in the 
requirements. 

A tool has been developed, to import 
documents into a relational data base. Each 
record of the data base corresponds to an 
item of a document, the access key is the 
item identifier. Tracing matrix is also 
processed, providing automatically links 
between the different documents. It enables 
the reading on the same screen of traced 
items. For example one can read 
simultaneously the User Requirements 
items, the corresponding Software 
Requirements items and the Acceptance 
Tests. 
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1. DOCUMENTATION MANAGEMENT 

1.1 Identification of requirements 

The problem of identifying precisely the 
requirements when developing software, is 


known by any one who has had to manage a 
subcontracted development on behalf of a 
final client : the operational team. 

One expects the project manager to answer 
such question as "what about this 
requirement, are you sure the modification 
we wanted has been correctly taken into 
account,... ?". 

Thus to avoid ambiguity and inaccuracy, for 
the development of a telecommunication 
satellites control centre, C.N.E.S. decided as 
early as 1989 to introduce identifiers in 
the User Requirement Documents. 


1.2 Identifiers 

In order to have a representative 
identification (trying to avoid FRED 1253), 
it was decided that an identifier must 
contain the acronyms of the main 
functionality concerned (TM, TC,...) and of 
the requirement, followed by a number, e.g. 
TMVISU090 for a requirement dealing with 
telemetry vizualisation. 


1.3 Editing rules 

In order to have a tool based on the use of a 
DataBase Management System, we chose 
editing rules to allow an automatic feeding of 
the database. To be followed the rules have to 
be simple : 

- an identifier must be preceded by a 
carriage return character and followed by a 
tabulation character, 

- when a modification is made to the 
requirement, the identifier must be 
preceded by a ”£” character in the next 
version of the document. 
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FONCTIONS 


2. THE DOCUMENT DATABASE 

2.1 Definition of the database 

The need at this stage was to gain an 
automatic access to an identifier, the main 
key of the database. 

But we also wanted to know : 

- which document it comes from, 

- which edition/revision of the document, 

- which paragraph (number and title) 
containing it, 

- the text of the requirement. 

For a requirement subject to a change we 
also wanted the change request number 
which it originated from. 


2.2 The database 

With 4 e DIMENSION® which is a user 
friendly DBMS running on a Macintosh® we 
have developed a tool named "TBD-pro" for 
"Traceur de Besoins durant le 
Developpement - version probatoire". 

TBD-pro was designed and developed at 
C.N.E.S. by M. Studnia, P. Pacholczyk, 

L. Baize. 

To avoid to be dependent on the word 
processor used to edit the document, the 
automatic feeding of the database is done on 
ASCII files. For the first "import" of a 
document, you create as many records as 
identifiers, for the next ones you only 
import into the database the requirements 
whose identifiers are flagged with the 
previous records of the database with the 
same identifier are flagged as invalid. 

In order to be able to trace the user 
requirements with other documents, we 
followed the same syntactic rules for the 
Software Requirement Document and for the 
System Acceptance Tests Document which 
were added to the database. 
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Paragrapho I1T. introduction to T.B.D.-pro 


Oescriptif 


Here is the very precise, testable second version ot the 
user requirement which must illustrate the presentation 
of TBD-pro at the Second International Symposium on 
Ground Data Systems for Space Mission Operations. 


3. THE TRACING DATABASE 

3.1 Definition of the tracing matrix 

We wanted to cross check the user 
requirements with the acceptance tests. The 
acceptance tests are a subset of the 
validation tests, which have to be checked 
against the software requirement. Thus it 
was decided to have a unique matrix 
containing the user requirements, the 
software requirements, the corresponding 
tests and the phases (validation/acceptance) 
the test is performed. Each identifier is 
followed by a tabulation character and a 
carriage return character separates each 
line of the matrix. 

UR ldent.->SR ldent.->Test->PhasesCR 


3.2 The database 

One of the main problems one has, reading a 
tracing matrix, is that very often the 
identifiers are not explicit. Thus the only 
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way to study it, is to have on one side the 
matrix, on the other side the concerned 
documents. 

As we had the document database, we decided 
to link the records with the matrix to offer 
a new matrix presenting the contents of the 
requirements or tests and not only the 
identifiers. 

Thus a new version of TBD-pro was 
developed, to include this functionality. 
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4. UTILIZATION OF TBD-pro 


4.2 Searches in documents 

TBD-pro offers the capability of searching 
through the documents. For instance, one 
may : 

- search requirements involved in a precise 
change request, 

- rebuild an out of date version of a 
document, 

- combine searches e.g. one may look for 
requirements containing strings like 
"telecommand" and "operator" and not 
"alarm", 

and then store and/or print the result. 


4.3 Other facilities 

TBD-pro offers the capabilities of searching 
through the documents on top of searching 
through the tracing matrix. 

One may perform any search he wants 
through the documents, and get onto the 
screen the corresponding selection of 
requirements and/or tests from other 
documents. 


4.4 Performances 

Our User Requirement Document contains 
1100 requirements, whole import takes 
less than one hour. 

The full matrix contains about 4000 lines. 
It takes about two seconds to change from 
one line of the matrix to the next one. 

Checking that no identifier from a document 
has been omitted takes about one hour and a 
half. 


4.1 Completeness of the matrix 

Because the documentation is in the 
database, TBD-pro offers the automatic 
check of the completeness of the matrix. You 
may print and/or store in a file the missing 
requirements. 


4.5 Planned upgrades 

Up to now, the version of TBD-pro is an 
interpreted one. in order to gain rapidity, it 
will be updated, to be compatible with the 
latest version ot 4 e DIMENSION®, and 
compiled. 

To be widely distributed, it needs to be an 
industrial product with a real 
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documentation and not only some developers' 
notes. 


5. CONCLUSION 

TBD-pro has shown it could be very 
helpful, because it is exhaustive, simple to 
use (menus, the result of any search may be 
stored and/or printed). It is the technical 
configuration management tool of the 
project. 


Macintosh is a registered trademark of 
Apple Computer, Inc. 

4 e DIMENSION is a registered trademark of 
ACI. 
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